fix: correct EU SIP allowlist docs#1068
Conversation
|
🌿 Preview your docs: https://vapi-preview-62ab032b-7e96-4d73-9652-249db5a82aa4.docs.buildwithfern.com |
|
🌿 Preview your docs: https://vapi-preview-40f4d927-b761-476b-b7b9-3d9bf28dfaf5.docs.buildwithfern.com |
dhruva-vapi
force-pushed
the
docs/eu-sip-allowlist
branch
from
187c329 to
55cb900
Compare
|
🌿 Preview your docs: https://vapi-preview-4a728c28-88f8-4ebc-affe-c3ef4402ae85.docs.buildwithfern.com |
| Vapi supports TLS for SIP signalling on port 5061 in both US and EU regions. For encrypted media (SRTP), configure your SIP trunk gateway with the `tls/srtp` outbound protocol option. See the [gateway configuration reference](/advanced/sip/troubleshoot-sip-trunk-credential-errors#gateway-configuration-reference) for details. | ||
| </Accordion> | ||
| <Accordion title="What do SIP 403 and 404 responses mean?"> | ||
| A `403 Forbidden` response with `X-Reason: Invalid credentials` usually means IP allowlisting or authentication failed. A `404 Not Found` response usually means Vapi could not find a matching account or called number for the request. |
There was a problem hiding this comment.
X-Reason: Invalid credentials is fabricated. This header is emitted nowhere in the platform. Verified against main just now: 0 occurrences of X-Reason anywhere in the codebase, and 0 occurrences of X-Reason or Invalid credentials across 24h of EU production SIP logs (logs-production-eu). SIP also has no X-Reason header — RFC 3326 uses Reason.
The 403/404 meanings are fine as generic SIP guidance, but please remove the invented header. One caveat worth a second look: the 403/404 you can actually observe in our infra are HTTP-edge (apoxy/Envoy) router replies — 403 = "request blocked", 404 = an internal admin path — which is a different layer from SIP-INVITE responses (those come from the jambonz/drachtio SBC). So the exact code semantics here shouldn't be sourced from the edge router.
There was a problem hiding this comment.
Confirmed and fixed in #1072. Verified X-Reason has 0 occurrences anywhere in the codebase (the edge fail() only sets content-type, and SIP reason data flows as sip_reason from jambonz, per RFC 3326), and that the 403/404 we actually emit come only from the apoxy HTTP edge (cluster-router: f.fail(403, "request blocked") and f.fail(404, "not found") on an internal admin path), not from SIP-INVITE responses. The follow-up removes the fabricated header and keeps the 403/404 FAQ as generic SIP guidance with actionable next steps.
| | --- | --- | --- | | ||
| | **5060** | UDP | Default SIP signalling | | ||
| | **5061** | TLS | SIP over TLS (SIPS) for encrypted signalling | | ||
| | **5060** | UDP/TCP | Default SIP signalling. EU traffic may use TCP on this port. | |
There was a problem hiding this comment.
TCP on 5060 isn't EU-specific. A live SIP OPTIONS probe returns 200 OK on TCP/5060 for both sip.vapi.ai (US) and sip.eu.vapi.ai (EU), and the SBC security group opens TCP/5060 region-agnostically. "EU traffic may use TCP on this port" implies a regional difference that doesn't exist, and could lead a US customer to believe TCP signalling isn't available to them.
Suggest: "Default SIP signalling. UDP and TCP are both supported in US and EU."
There was a problem hiding this comment.
Confirmed and fixed in #1072. infra/aws/cloudFormations/jambonz-large.yml opens tcp 5060-5061 plus udp 5060 from AllowedSipCidr in a single region-agnostic template (no Condition/!If gating, no separate EU template), so TCP/5060 is not EU-specific. I used your suggested wording for the port note, and also flipped the US signalling rows to UDP/TCP across the quick-reference and firewall tables so the protocol columns are consistent across regions.
4 participants
Description
Problem: The SIP docs mixed US-only allowlist/TLS guidance with EU SIP setup, so EU customers could configure the wrong host, IP, or port.
This PR updates the SIP networking reference and provider setup guides to describe region-specific SIP signalling, EU TLS on
5061, and EU static RTP media.fern/advanced/sip/sip-networking.mdxwith EU TLS on port5061, EU RTP media on63.182.83.170, and the US dynamic-RTP caveat.fern/advanced/sip/sip-trunk.mdxandfern/advanced/sip/troubleshoot-sip-trunk-credential-errors.mdxso allowlist guidance is region-aware.Testing Steps
fern check-- passes with 0 errors and 5 existing warnings.git diff --check-- no whitespace errors.sip.eu.vapi.airesolves to63.182.83.170, and TLS on port5061succeeds.